In hardware.

tags: ssdt420crypto

My laptop, a Thinkpad T420, is pretty neat. I've had it for a year and figured it was time for an upgrade, one that I had been planning on for awhile.

The T420 includes an mSATA port. As the name implies, it's meant for really small hard drives. I bought a 64 GB (60 GiB) mSATA SSD. This post covers the why and how I added it to my laptop.

SSDs have many benefits over traditional hard drives. I am most interested in having faster disk access and possibly lower power consumption, if I can get my platter-based hard drive to spin down if I don't need it. I want a hybrid setup, where the SSD is used mainly for the operating system, and the other hard drive for large, less-frequently-access files (music, large datasets for my research, backups, etc).

Keeping an eye to security, I want the speed of the SSD but still the security of my full-disk encryption setup, covered previously. So I will still be using LUKS. It's been harder to find much information on using multiple hard disks with LUKS and SSD encryption, so hopefully this post will help.

Also, when it comes to security, I want enough security/encryption to be careful, but not paranoid or terribly inconvenient (yes, yes, I know security and convenience is a tradeoff). If my laptop were ever lost or stolen, my mind would be at ease that its contents would not be recoverable to any casual (or even determined) third party. However, I realize that government-grade resources may circumvent my encryption, or I could be phished, fall prey to malware, or otherwise compromised.

When it comes to hardware, the first priority is to not use an SSD with a SandForce controller. SandForce controllers play tricks with compression to get a higher write speed. Since only encrypted data will be written to the SSD, compression will have no effect and will just slow things down. So it's better to have a "dumb" controller that doesn't try to compress my data.

The Mushkin mSATA drives are highly rated, but they use SandForce controllers, so they're out. The Crucial m4 uses a Marvell controller without any compression. So, that's the one I ordered.

Here's the SSD, it's really tiny:

I opened up a back cover, note it's even smaller than the RAM:

And here is the SSD installed (I moved the WWAN leads to the side):

(Here's the Lenovo T420 Hardware Maintenance Manual for the official instructions.)

I booted it up, and saw that it was recognized:

It looks like it already has the latest firmware, 07MH (as found on the Crucial website):

So I won't bother with trying to update the firmware.

Now for some quick benchmarks, as suggested on the Arch wiki. Below, /dev/sda is the regular hard drive and /dev/sdb is the SSD. First, I use hdparm:

The cached read for the SSD is pretty much the same, but the buffered read is 2.5x faster.

Now for gnome-disks (in the gnome-disk-utility package):

Again, reading is about 2.5x faster. Writing is about 55% faster, and the access time is 100x faster!

Finally, using dd. This requires working within a filesystem, but none exist yet on the drive. So I set it up as a GPT drive and create a single partition:

Then I create an EXT4 filesystem in the new partition:

And finally I mount it:

As far as partition alignment issues go, the partition was created starting at sector 2048, so we're fine. Now for the dd benchmark:

When I run the final command 5 times and average the results, the mean buffer read time is 5.7 GB/s. The above benchmark showed that the write speed is 111 MB/s and the (unbuffered) read speed is 277 MB/s. The three benchmarks all agree with each other and are in the right range of other SSD drives tested by others.

A final note is that while the two SATA ports in the T420 are SATA III (6.0 Gb/s, or 600 MB/s), the mSATA port is limited to SATA II (3.0 Gb/s, or 300 MB/s) (reference). My (unbuffered) read speeds are approaching link capacity. It would be interesting to see my laptop's performance using a standard-sized SSD with the other SATA interfaces. Maybe someday I'll put one in.

Finally, I unmount the drive and wipe it using the ATA Secure Erase command, as outlined on the Arch wiki. One caveat was, during step one, that the status was reported as "frozen" until I suspended and then resumed, then it was "not frozen" and I could proceed.

Because this post is long enough, I'll split it here. I've decided to completely re-format my drives so I can start from scratch. I will use a dual-boot setup with Windows 7 and Arch Linux. I'll keep Windows 7 on the hard drive (I rarely use it, so why devote valuable SSD space to Windows?). I'll use LVM on LUKS for Arch with data split between both drives, fully encrypted.